Organizations, such as private companies or governmental agencies, commonly purchase relatively complex third-party products that help them achieve their primary goals. For example, a company that manufactures and markets electronic products may need a third-party human resources product to help the company manage its employees, a third-party supply chain product to help the company manufacture its products, a third-party customer relationship product to help maintain relationships with customers, and the like. Generally, such third-party products provide the desired functionality, and manage large amounts of data that are relevant to such desired functionality. Management of data is in itself a highly complex function, and third-party products frequently incorporate a database management system (DBMS) that is manufactured by yet another party that specializes in the management of data. A DBMS is commonly a combination of complex database access routines that manipulate data structures, and the actual data structures (i.e., the “database”) manipulated by the database access routines.
Typically, a third-party product interfaces with a DBMS through a programmatic interface that is native, or unique, to that DBMS vendor. Such native database interface allows the third-party product to store, retrieve, and modify data necessary to the functionality of the third-party product, in a manner dictated by the DBMS vendor.
Third-party products typically provide user interface functions that allow employees of the company to enter, retrieve, and modify data maintained by the third-party product. Often a third-party product will also provide a programmatic interface, such as an application programming interface (API), that allows a company that has purchased the third-party product to develop software that can interface with the third-party product programmatically to enter, retrieve and modify data. Consequently, the company may have no ability to directly access the underlying DBMS used by the third-party product, and thus, with respect to the underlying DBMS system, may be limited to the functionality implemented by the third-party vendor. If the company would like additional access to the underlying DBMS, the company must request the third-party vendor to implement such functionality, which may or may not be feasible, and even if feasible, may not be implemented in a timely manner by the third party. Such a third-party product will be referred to herein as a “closed system,” since the company using the third-party product has no, or only limited, ability to modify the third-party product, and does not have direct access to the underlying DBMS.
Such closed systems can make data synchronization with other systems difficult, or impracticable. It is not uncommon for a company, over time, to develop multiple systems that rely on the same data, requiring propagation of data from one system to another system. This can happen, for example, as a company grows and purchases other companies, which have in place their own third-party products, e.g., a customer relationship management (CRM) product, that differ from the systems of the purchasing company. It may be highly desirable to keep the two different CRM systems in synchronization with one another, but this may not be possible because the systems may be provided by two different vendors, even where such vendors utilize the same underlying DBMS system.
In some situations, an organization may implement multiple instances of the same third-party product throughout the organization, but desire synchronization among such instances, or desire synchronization of modifications made by client instances with a master instance. Again, such synchronization functionality, if not expressly provided by the third-party vendor, may not be possible. Accordingly, there is a need for a mechanism that allows synchronization among closed systems, and that does not require modification of a closed system, or direct access to an underlying DBMS used by the closed system.